In computing, an event is a detectable occurrence or change in the system's state, such as user input, hardware interrupts, system notifications, or changes in data or conditions, that the system is designed to monitor. Events trigger responses or actions and are fundamental to event-driven systems. These events can be handled synchronously, where the execution thread is blocked until the event handler completes its processing, or asynchronously, where the event is processed independently, often through an event loop. Even when synchronous handling appears to block execution, the underlying mechanism in many systems is still asynchronous, managed by the event loop.
Events can be implemented through various mechanisms such as callbacks, message objects, signals, or interrupts, and events themselves are distinct from the implementation mechanisms used. Event propagation models, such as Event bubbling, capturing, and pub/sub, define how events are distributed and handled within a system. Other key aspects include event loops, event queueing and prioritization, event sourcing, and complex event processing patterns. These mechanisms contribute to the flexibility and scalability of event-driven systems.
In contrast, serve a broader role, encompassing commands (e.g., ProcessPayment), events (e.g., PaymentProcessed), and documents (e.g., DataPayload). Both events and messages can support various delivery guarantees, including at-least-once, at-most-once, and exactly-once, depending on the technology stack and implementation. However, exactly-once delivery is often achieved through idempotency mechanisms rather than true, infrastructure-level exactly-once semantics.
Delivery patterns for both events and messages include publish/subscribe (one-to-many) and point-to-point (one-to-one). While request/reply is technically possible, it is more commonly associated with messaging patterns rather than pure event-driven systems. Events excel at state propagation and decoupled notifications, while messages are better suited for command execution, workflow orchestration, and explicit coordination.
Modern architectures commonly combine both approaches, leveraging events for distributed state change notifications and messages for targeted command execution and structured workflows based on specific timing, ordering, and delivery requirements.
An event is an abstract data type with a boolean state and the following operations:
Different implementations of events may provide different subsets of these possible operations; for example, the implementation provided by Microsoft Windows provides the operations wait (WaitForObject and related functions), set (SetEvent), and clear (ResetEvent). An option that may be specified during creation of the event object changes the behaviour of SetEvent so that only a single thread is released and the state is automatically returned to false after that thread is released.
Events short of reset function, that is, those which can be completed only once, are known as futures. 500 lines or less, "A Web Crawler With asyncio Coroutines" by A. Jesse Jiryu Davis and Guido van Rossum says "implementation uses an asyncio.Event in place of the Future shown here. The difference is an Event can be reset, whereas a Future cannot transition from resolved back to pending." Monitors are, on the other hand, more general since they combine completion signaling with Mutual exclusion and do not let the producer and consumer to execute simultaneously in the monitor making it an event+critical section.
|
|